The techniques of the prior art and their drawbacks shall now be discussed in the particular case where the secure information storage devices are authentication devices used by the third parties to authenticate the holders of these devices. It is clear however, as already indicated here above, that the invention can be applied regardless of the function or functions used to provide third parties with the information contained in the secure information storage devices.
Applications using secure access can be classified under two categories:                applications using online (synchronous) securing such as for example bankcard applications and mobile telephony (SIM) applications;        applications using deferred-time or offline control securing such as for example applications for secure electronic mail or electronic filing of tax returns.        
The authentication architectures implemented in both cases are different and quite exclusive of each other. In the former instance (online securing), the authentication architectures are centralized. In the latter instance (off-line control securing) they are decentralized. The centralized architectures cope poorly with the mutualization of applications from the different service providers because, by nature, that is only one centralized element that performs this authentication.
Strong authentication devices (for example with dual authentication: “what I know”, PIN code and “what I have” authentication, smart cards or dongles) have already been implemented in both types of architecture. However, there is no instance where one device lends itself well to different types of strong authentication (OTP, CS, PKI) at the same time and is capable of being an authentication element equally well in centralized or decentralized architectures. On the contrary, the authentication devices are usually specialized in a strong type of authentication as well as in a given architecture, since it is not possible to cross all types of strong authentication with all types of architecture.
In other words, each third party implements authentication devices that are proper to it and specific to a method of authentication (OTP, CS, PKI etc.) and to an authentication infrastructure (centralized or decentralized architecture). The costs of investment and exploitation are therefore not mutualized among different third parties. The management of the authentication devices is cumbersome because these are hardware devices and each instance calls for a specific recording infrastructure with specific learning costs and costs induced by the absence of mutualization.
To overcome this problem, several technical solutions have been proposed such as for example the one called “Global Open Platform” (cf. “Global Platform Smart Card Management System Functional requirements, version 4.0”), enabling several third parties (service providers) to use one and the same smart card type authentication device without being linked to the entity (also called an operator) that manages cards (especially their supply and issue).
However, this prior art technique is not optimal because, at the end of a pre-customizing phase, it makes use of trustworthy third parties to make the third party service provider independent of the operator.
Furthermore, this prior art technique is extremely rigid because the card issuer must, if possible, have advance knowledge of the applications that will be placed in the card. Novel applications can be downloaded during the service life of the card. However, it is the entire image of the card that will have to be reloaded.